Description

This change ensures consistency with how paths are parsed when updating a domain path.

The modified line was passing the domain name as a literal string, but it is actually interpreted as a regular expression internally.

I couldn’t find a way to exploit this issue, but it could still cause data corruption if a domain name accidentally contains regex metacharacters.

Note that this same technique is already used in a similar situation on line 1118.

A common example is when an organization uses its DNS name as the "domain" (tenant), like company.com.

In this case, the . (dot) is treated as a regex wildcard, meaning it can match any character...

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

This fix was not tested. I am not a Java developer, and I have no skill for such a thing.

How did you try to break this feature and the system with this change?

I could trigger, but I could not exploit this bug.